Thanks @glady for that proposal! The downside of introducing the new extension point ResultHandlerInterface like that is with standalone usage of the Platform component. So deptrac is great proof for having a proper decoupling, but imagine someone is not using the Agent component and wants to leverage the TokenUsageResultHandler as well - of course that's possible but only with their own glue code sticking the Platform's classes together.

An event-based solution didn't fly or was too much of hustle?

Edit:Maybe this could sit on top of #575?

@chr-hertel The event based solution had some more things to think about, I didn't want to introduce an additional dependency without thinking about more proper events. Not everyone is interested in using that, so he will need to write some glue code (like we also need with the agent usage and the processors) in order to "activate" it, so he will at least need to add a subscriber that still would call the result handler (so this class or something similar would be needed anyway). Thats why I decided to build an result output processor entry point like its used in the examples (and in the bundle as well).

My opinion: to introduce an event dispatcher with proper events (for more events than just result) is another (bigger) scope I didn't want to touch yesterday.

to introduce an event dispatcher with proper events (for more events than just result) is another (bigger) scope I didn't want to touch yesterday.

fair enough - and i agree that we could try to keep the event dispatcher dependency optional

other than that we could have input/output extension points instead of events, similar to the agent - to skip the event-dispatcher dependency - cc @OskarStark @RamyHakam any opinion on event dispatcher vs explicit lib-specific extension point?

The explanation sounds valid so let's try the extension points 🙌

alright, just lost my mind, was close to proposing OutputConverterInterface and realized that we have a ResultConverterInterface already 😂

So we have already an explicit extension point - but we can't directly use it with additional result converters for the tokens - now i wonder if we can extend the current ones without bringing even more concerns to the existing implementations.

@chr-hertel yes, I recognized this result converter interface too, but it is "first match" and just handles the model-based conversions (raw result -> result), which is something that should work out-of-the-box not like the optional token usage. Maybe the token usage can be an option to be put to those converters (as option given to Platform::invoke call). In this case my classes would be obsolete, indeed.